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Method for developing complex systems. 



The invention relates to a method for developing a family of complex systems 
having a common software architecture platform. 



5 Such a method for developing a family of complex systems is known from the 

paper 'Medical product line architectures' by B J. Pronk in Proceedings of the First IFIP 
Working Conference on Software Architecture, 1999. 



l0 The cited paper discloses a development method for developing diagnostic 

M equipment. The known development method starts from a ccmceptual arehitecmral 
vZwhich describes design solutions and rules as applied to tackle the mam architectural 
issues of decomposition vs. co-operation. On top of the conceptual view, additional 
eonstructsneces^ 

v,;^ rr^rfel is set ud The additional constructs include e.g. 1/U - 
15 this way the requirements object model is set up. ineauu* 

v ;™ ^r^ratine system and also specific hardware choices, 
classes, caching mechanisms, operating system «»• ~= *~ 

A goal of the invention is to provide a development method for a family of 
complex systems that supports simultaneous development of several members of the family 

20 as well as later addition of new members. r . 

This goal is achieved by a method for developing the family of complex 

systems according to the invention 
the method comprising 

. set up of a functional required specif which includes use cases that desenbes 
« interaction of users with said complex system, in terms of abstract concepts 

- set up of a requirement object model which e*p*ins me abstract concepts in terms of a 

structured vocabulary wherein - 
_ ^ use cases are developed hand-in-hand with the requirements obj ect model. 
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2 09.03.2000 
The functional requirements specification (FRS) and the requirements object 
model together describe a domain, which is defined here as a concept space of systems A 
domain is defined as a conceptual space of possible systems, which includes the current and 
future members of the product family. In other words, the specifications and the model 
5 should be as much as possible independent of the concrete choices for the individual products 
to be implemented as members of the family. Thus, the domain Is as much as possible 
independent of particular choices for the individual current and future members of the 
product family. The essential differences and commonalties of systems within a domain are 
captured. The requirements object model contains those items necessary to express what 
1 0 happens in the system, but not items relating how things happen in the system. The 
requirement object model provides a structured vocabulary for the FRS. 

The FRS specifies the interaction of the complex systems with their users. 
Notably, the FRS specifies the activities which are performed in the interaction of the 
complex systems with their users, i.e. 'what' the complex systems do. This is preferably done 
in terms of the use cases which are usually written in a natural language such as English. The 
requirements object model specifies the concepts to which the activities specified in the FRS 
relate. The FRS may be divided into several chapters. Preferably, the requirements object 
model is written in an object modeling language such as UML. 

Authoring the use eases is done hand-in-hand with the set-up of the 
requirement object model and the use cases are expressed in the terminology of the 
requirement object model. This yields clarity and consistency of the functional requirement 
specification. In particular, an FRS authoring team is established for each chapter of the 
functional requirement specification (FRS). A single object model control team (OMCT) is 
responsible for the maintenance of the requirements object model and its internal consistence. 
The requirement object model is constructed by overlapping modeling teams, each of them 
comprising an FRS authoring team and the OMCT. Modeling sessions are not overlapping, 
the authoring work can be done in parallel. 

The resulting requirements obj ect model can be used as a starting point for the 
development of a design object model. The final design object model will then be an 
30 extension of the requirements object model. For this to work, the transition from 

requirements object model to design object model involves a reinterpretation of the model 
items from conceptual notions into notions at the level of a programming language. 

The development method according to the invention achieves an improvement 
of the traceability in that there is a clear relation between items in the requirements model 
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and in the design model. Notably, the invention makes it possible to trace implementations of 

specific requirements. 

The approach of authoring the use cases hand-in-hand with the set-up of the 
requirement object model achieves that the development method takes account of future 
5 evolution both from a conceptual point of view as generated in the FRS as well as from the 
point of view of the interactions between systems and users as generated by the requirement 
object model. In particular, future requirements as foreseen from the requirement object 
model are also included in the FRS. 

The development method according to the invention achieves that owing to the 
10 hand-in-hand set-up, the combination of the FRS and the requirement object model are more 
complete and more accurate. That is, the development method of the invention supplies a 
complete description of all family members. Notably, completeness and accuracy are 
improved because any miaunderstandings are adequately resolved almost immediately and do 
not propagate into further stages of the development. 
15 The advantages of having a complete and accurate combination of the FRS 

and requirements object model also pertain to the development of a single new complex 
system. That is, the method according to the invention may also be advantageously applied to 
me development of a single new complex system. A single new complex system may be 
considered as a family in itself having only a single family member. Moreover, when 
20 developing a family of several members, superfluous diversity within the family of complex 
systems is avoided. The software architecture developed according the method of the 
invention remains employable when next realisations within the family of complex system 
are constructed. Notably, the software architecture is again employable when a new or other 
functionality is added to the present or previous generation of complex system and also when 
25 a next generation of complex systems is constructed. 

Authoring the use cases hand-in-hand with the set up of the requirements 
object model is preferably achieved in that the use cases are mainly authored simultaneously 
with the set up of the requirements object model. It appears that in practice it may be allowed 
to author a draft version of the use cases before any modeling is done in order to elaborate the 

30 use cases in full detail. 

It is noted that the concepts of the functional requirements specification and 
the requirements object model were suggested per se in the book 'Object-oriented Software 
Engineering: A Use Case Driven Approach', by Ivan Jacobson et «/.(ACM Press/Addison- 
Wesley 1992). However, there it is taught to first complete the functional requirements 
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specification before set-up of the requirements specification. Moreover, the cited reference 
concerns development of a software platform for a single complex system. 

These and other aspects of the invention will be elaborated with respect to the 
preferred implementations as defined in the dependent Claims. 

Preferably, the method according to the invention is implemented in that 

- the functional requirements specification includes one or more chapters and one or more 
FRS authoring teams are established for separate chapters 

- a single object model control team control internal consistency of the requirement object 
model 

- one or more overlapping modeling teams are formed where each modeling team includes 
members of the object model control team together with one or more members of 
respective FRS authoring teams, 

- Which overlapping modeling teams for their chapters construct use cases and provide the 
portions of the structured vocabulary. 



While writing the use cases conceptual difficulties and shortcomings of the 
current requirements object model become apparent and the requirements object model is 
amended to overcome such shortcomings. Notably, such shortcomings in earlier versions are 
overcome at an early stage of the set up. Thus, it is avoided that shortcomings persist in next 
versions where they are often difficult to trace and repair. Further, h is achieved that a lot of 
domain knowledge is exchanged and shared early in the development method. As the OMCT 
is involved in all of the overlapping modeling teams the internal consistency of the method is 
achieved without much additional effort. 

Because overlapping modeling teams are employed it is made easier to involve 
a large number of participants in the development process of the family of complex systems. 
In particular, tasks may be performed in parallel while internal consistency of the 
development process is maintained. 

Preferably, in one or several of the overlapping modeling teams an initial 
model is constructed. In mis initial construction domain knowledge is shared among the team 
30 members. Starting from the initial model use cases are written. Subsequently, in return 
sessions the model is fine-tuned so as to form a consistent basis of the FRS. 

Respective FRS authoring teams are preferably active in parallel for authoring 
the use cases of respective chapters. Thus, time schedules are relatively easily met. The only 
possible bottleneck is formed by the OMCT, which is shared by all authoring teams. 
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These and other examples are elaborated further and discussed by way of 
example with reference to the embodiments and implementations discussed hereinafter. 

In many instances it is a good idea to conceive products to be introduced to the 
market in the context of a product family, whose members share several internal and external 
5 properties. Such a product family approach has many advantages, among others in the areas 
of marketing, development, manufacturing, and niaintenance. During the development of 
such a family it is important to specify what is to be expected of these products in a 
sufficiently precise way so that all people involved (from marketing, development, etc.) agree 
on it without the possibility of significant rmsund^rstandings. This is called the requirements 
10 specification. (This is not to be confused with a specification of what is desired unilaterally, 
e g., by the marketing apartment, or a specification of how this is realised.) Note that for a 
product family the requirements specification should make clear the properties of each 
individual member of the family while also making explicit what they have in common. 
Depending on the circumstances such a requirements specification could consist of a single 

1 5 page or of thousands of pages. 

Furthermore, from a development point of view, the method according to the 
invention achieves that a smooth transition is ensured from the requirements specification to 
the subsequent development phases (design, implementation, etc.). Among others it should 
be possible to use the documents developed for the requirements specification as a basis for 

20 the following phases, without, however, limiting the designers' freedom unnecessarily. 

The method according to the invention is suitable for families of complex, 
software-intensive, electronic products. The following different aspects of the invention will 
be discussed in detail: the kind of development proj ects for which it is most suited, the 
documents that are produced, the way in which it supports product families, the specification 

25 process, and the transition to the design phase. 

The approach of the invention has been applied, among others, in a large 
development project for a family of equipment for medical imaging. Medical imaging 
systems are for example x-ray examination systems, magnetic resonance imaging systems, x- 
ray computed tomography systems, and diagnostic ultrasound systems. The domain of 
30 medical X-ray systems has the following features: 

The market is relatively mature: Even the relatively modem systems with digital image 
processing have been around for more than ten years. Consequently, the expectations of 
the users are very high and to meet those expectations, the systems otter many 



1. 



Printed:T7-1 1-2000 



Ontvang eji : s/ 3/00 10:68- .. „ „ 

1 0 • *31 AO 2743 488 



PH-NL000121 EP-P L — — ~— - J i SPEC 



10 



6 09.03.2000 
possibilities to fine-tune them to the precise task at hand. This leads to a high degree of 
complexity. 

2. High demands are placed on the safety and reliability of the equipment This is one of the 
reasons why government institutions, such as the American FDA, apply strict rules not 
only to the equipment itself but even to the development process. 

3. The number of systems sold does not run in the millions, but in the thousands. Moreover 
there are many possible options to configure systems. As a result it rarely occurs that two 
systems have exactly the same configuration. Therefore ft is impossible to test every 
possible configuration exhaustively. 

4. Developing such systems requires the co-operation of many people with vastly different 
expertise, ranging from VLSI designers to medical application specialists. 

The project itself has the features of: 

a) It is large, involving over a hundred developers, many of whom were new to the domain. 

b) K is carried out jointly by several der^rmientstn^ 
15 product lines in relative isolation. As a result the different experts often used different 

concepts and terminology for comparable things. 

c) Although time to market is, of course, important, the complexity of the developed 
systems nevertheless leads to a project duration of several years. The resulting 
architecture should have a lifetime of well over ten years. 

Because of the above factors, ft is clear that an exhaustive and precise 
specification was necessary as a basis for further development. Specifying the required 
fimctionality of complex systems like medical imaging systems in sufficient detail typically 
involves a large amount of documentation. The method of the invention structures this 
documentation as follows: 

a) The Commercial Requirements Specification (CRS) describes the positioning of the 
system family members in the market It only describes their features in very broad terms. 

b) The Systems Requirements Specification (SRS) sketches the features of the femily 
members, typically in the form of bulleted lists and tables without much explanation of 
the terms used. 

30 c) The Functional Requirements Specification (FRS) gives a complete and detailed 

description of the behaviour of the systems in the family. Mo st of this is done in the form 
of use cases: pieces of English text that describe the interaction between the system and 
its users. Despite its name, the FRS can also contain non-functional requirements, which 
can either occur in the use cases (e.g., acceptable response times for particular functions) 



20 



25 



Printed: 17-1 1-2000 



§ 



^«%mil00121 EP-P 



10 



IS 



20 



25 



30 



7 



09.03.2000 



or in a separate chapter. Since the total size of the FRS can be very large, it is often useful 
to divide the FRS into chapters, so that several authors can work on it in parallel. The 
method according to the invention proposes to choose the chapters according to areas of 
functionality, for example, distinguishing different kinds of users or different phases in 
the user's workflow. For medical imaging systems, examples of chapter titles are 
Administration, Patient and Beam Positioning, Acquisition, Reviewing, and Archiving. 
Often these functional areas coincide with areas of expertise for the several FRS authors 
involved. Note that this subdivision of the FRS does not automatically imply a similar 
subdivision in the design of the product family, 
d) The tenements object model is expressed in UML. This model explains the concepts 
that play a role in the interaction between the systems and their users and the 
relationships between these concepts. These concepts can range from concrete, tangible 
pieces of hardware (e.g., an X-ray detector), via electronic representations of real-world 
items (e.g., a patient folder) to abstract entities without a counterpart outside a computer 
(eg user preferences). This requirements object model provides a structured vocabulary 
for the FRS. In other words, all nontrivial words that occur in the use cases should occur 
in the requirements object model as names of classes, attributes, association roles, etc. 
Although the FRS is subdivided into chapters, there is a single, shared object model, 
which provides the common ground that ties the FRS chapters together and ensures that 
they talk about the same things. The structure of a use case is explained now in some 
detail. For medical and similar professional electronic equipment, a typical use case 
involves only a single user. In most cases this user has a fakly sirr^le interaction with the 
^ (pushing a button, turning a knob, selecting a menu item, etc.), so the sequence of 
events is not complex enough to justify, for example, a UML sequence diagram. 
However, the effects, within and around the system, caused by this interaction need to be 
described very precisely to avoid ambiguity. For example, when increasing the unage 
contrast, it is important to specify precisely which set of images are affected by the 
change and whether the new contrast will still be effective when the image s are viewed 

tirr*. This is where the connection with the model comes in as a conceptual 
framework* interpret these detailed descriptions. In principle, these descriptions could 
be expressed in a formal language, like OCL, but a nabiral language such as Enghsh » 
preferred because the specifications should be readable by different kinds of stakeholders. 
Tot only software developers, in fact, the goal is to write specifications mat can be read as 
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are used. 

Developing an object model during the requirement specification activity is a 
novel and inventive element in the method of the invention. According to the invention the 
5 use cases are developed hand in hand with the requirement object model combining to a 
certain degree the requirements specification and analysis activities of other methods 
Although writing use cases is not entirely excluded before set up of the requirements object 
model, the requirements specification is not considered finished until these use cases are 
expressed in me terminology defined by the requirements object model. 

10 it is noted that the construction of such a requirements object model is not 

completely comparable to what other methods call analysis. The difference is that often such 
an analysis is a first step in deciding how to implement the system's functionality whereas 
according to the invention, the requirements model contains just enough information to 
express what the systems do. This distinction is much clearer man the distinction between 

15 analysis and design in the known methods. 

The most important advantage of the approach of the invention is a 
significantly improved clarity and consistency of the FRS. While this could be achieved to a 
certain degree by including a flat glossary, the additional structure expressed in the object 
model by indicating the relationships of different items with each other increases this clarity 
and consistency. For example, if me model indicates that an X-ray system can have more 
than one X-ray detector, it becomes clear that a use case cannot just mention 'the detector" 
but must indicate which specific detector is meant Other advantages of the approach will be 
discussed below in relationship with the modeling and design processes. 

Since the method according to the invention result is a design specification of 
a whole family, rather than of a single system, the specifications reflect that fact The most 
important principle is that, as much as possible, the specifications and the model should not 
describe one or more individual products, but a domain. Hence, the specifications and the 
model are made independent of the concrete choices for the individual products to be 
implemented as members of the family. In this way, the specifications and the model form a 
common basis for the whole product family, stressing the commonalties instead of the 
diflerences between the products. This principle is important because it helps to eliminate 
inessential differences between the products that would otherwise arise naturaUy, especially 
when different people are responsible for different products in the family. Nevertheless it is 
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of course necessary «o express the possible variation points between ft, *~ *° 
domain. Inthereo^n^obi.*^ 

o^bolass. Whaler this is foreseen, such a subclass can aWy 
mil, but this is not necessary. For example, an X-ray detector may be a fum de*c^a 
combination of image intensifier and TV camera, a flat Estate detector, or any other 
Idnd of detector rnat may be inventedmthe future. 

b) Multiplicity. Aggregations or aviations in the model can nave ranges for the* 
muiupliciues. For sample, the model may indicate that an X-ray s^em may .nutn 
one or more X-ray detectors, but of course any specific system will have a specific 

number of detectors. . • 

c) Attributes: A particular system may have a particular value for an attribute of an ob,ect tn 
' tal from me type of tie attHbute in 0, model. For examp.0 the maximum 

resolution and the maximum number of images taken per second may vary among 
dif^ detected even if they am of tta . „„, . ^ 

I, is noted however that occurrences of the mechanisms above do not always 
correspond wim system variation points: Tney could also apply to the data that ism~d 
irXgle system For example, a patient folder could contain an arbtary number of study 
flers, and this number can even change over time wimin a single X-ray system. 
Variatior^mme use cases between t^systemsm^domam 

each system supports its own subset of*, use cases. Moreover, the behaviour 

oacn system ^„ aweteT8 which could differ between the systems. 

certain use cases may depend on certain parameters, which coma 

In this case itisuseftJ to include th^ep 

In this case, ix ib use , „ n „ A mem A on several kinds of items in the object 

attributes. More generally, the use cases can depend on several 
; ^d, e g., the specific class of an object, the number and the idennty of the objects 
, model, e.g., ul= »^ tm ~*,t^. rais dependency can also occur rf the 

Involved in an association, or the value of an attribute. CThis dependency 

could depend on the number of study folders in a patient folder.) 
msom.ca.ea.^sl-ightfcrwatd* 
0 enough, but an in-depth, domain-specific analysis is rented to ^ 

d^c^ces and commonalties between the systems in a domau, For example. whUe 

ZlZ, the subsys^m responsible for controlling ute major mo vmg parts m mesy^ 
rTaXishas shownmatute essential concepts to the area of geometxy were n« motors, 



[primed ?l7^Tl-20 00] 



uqTvang e.n = B/ 3/00 lO:5S; 



~ , ^ +31 40 274348S -T^, 

PH-NL000121 EP-P *-~3~-±~-JizM^ 



EPO/EPA/OEB R±J-W±Jlc S Paolna _ 1e 



"0-773 SPEC 



10 09.03.2000 



10 



brakes, and C-arms, but positions and movements. All the systems ta ^ 4^ ^ ^ 
nand, two aspects may represent a movement: 

- What is it, clinical rnupoae? For example, rotating the X-ray beam around tta ^hent, „ 
moving a detector out of the way. 

- In which way does the user control it? For ^ movemmt ^ ^ 
manually or by a motor. 

On the basis of this mentation, the geometries of the systems in the 
domata could be disttoguiahed by which cUnleal kind, of movement fl>ey suppon and by the 
control parameter of these movements (e.g„ the maximum speed). 

When all these measures have been taken, an individual system (possibly a 
P^tothefiunUrtcanbespedfiedbyd* 

fixing the variation points in the requirements object model (i.e., specifying the subclass in a 
generalisation, the multiplicities of an association, or the value of an attribute). 

During the specification process it may be helpful to consider a small number 
of specrfic systems, which may be acrual envisaged members of me product family or 
fictmoua ones. By doing mis, 1, is ensured mat the abstractions in the FRS and the model 
ach^Uy fit the intended concrete and specific instances. ^specific systems can also bo 
meluded in the model, but in that case they must be clearly rnarieda, examples 

- It appears advantageous to involve as many stakeholders as possible in me requirements 
n.ecrficatJon process, since this will increase subsequent acceptance of the specifications 
Compared to the CRS and the SRS, the involvement of developers in the FRS and object 
model will be typically be higher, whereas the involvement of marketing people will 
typically be lower. Por the FRS authoring and object modeling the following team 

25 structure has appeared advantageous: 

- An FRS authoring team for each chapter of the FRS. Such a team will consist of the 
primary author of the FRS plus a number of supporters, which can be experts in the field 
or representatives of stakeholders. The responsibilities of this team are to write the FRS 
chapter and to contribute to the requirements object model. 

30 - A single object model control team (OMCT). This team consists of a small number of 
people (three or four), including at least one person with experience in modeling and 
possibly a designated scribe. This team does not need much domain knowledge to begin 
with, since the FRS authoring teams will contribute that The responsibility of the OMCT 
is to maintain the object model and to ensure its internal consistency. 
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ModeUr, can begin «**» *e people in the FRS tean have a good, but 

Llianty by being Involved in previous development project, for stmxUr systems. When 

fennbantyoyoeing discussing informal use cases 

-.eesaan this understanding can ^ . . . ,, 

, order to obtain a single, consists object mods! that prides a basrs for all 

«« FRS charters the model is constructed by overlapping modeling teams, where each 

modeling session. typically lasnng one or more weelcs, m wen ..^v 

10 UZx domain pledge and together construe, a piece of the object »^*»* 

atalforafuUdayperweck.inordertoflM-tunctrttsmodel. 

model, so the model is changed to solve this problem. 
, -> A ^ eleeant way has been found to express a certain point in the model. 

b) A more elegant way rHimeein the model and this must be integrated 

c) Another modeling group has proposed a change in me moaei 
on with the use cases written by the current modeling group. 

20 ^Modeling outside these modeling teams should be discouraged, BU1 ^ 

s^ueutrnode^ 

T J^u « more difficult man a discussion about a problem and how to solve it 
■ *.-^^^bemiusated by clever and carefid plaiming of the 

members must be familiar with the complete obj ect model and have 

the contents of the FRS chapters. as is that a lot of domain knowledge is 

30 The advantage of the above process is that a lot ol qomain 

exchanged and shared early in the development process, 
ZTdgecanbeconsolidat^mth^ 

overlapping groups has the following advantages: 
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1. Many people can be involved to the process, which increases ^ n ^ 
and acceptance of ita outcome. "*««ness, 

2. A lot of work (writing the FRS chapters) can be done in parallel 

3. The modeling itself takes place in manageable groups 

5 ^ ™dTb^ 

model but also w modeling style. 

Tlte re^urem^tts specification artefacts describe above serve as a wU d 

^^^Sfflodel itself but its interpretation is changed. For example, a TJML claa^fothe^model 

but in the design model the same UML class represents . programming c ^ 
Snarly, an ^ of . ^ J^^^ 

possibly a data member. Of course, this step towards an initial design .node, does revolve 

zrs'T' ^ ** ***** ° f ^ ^~ simper 

bm probably because of mis, the menta, stop is a difficuh one for many develo " ^ 
takes some time to get used to. ueveiopersandtt 
20 pp. 

following: ^ — " ~ * ^ model consist of iterative* doing one of me 

a) Extensiom Adding packages, clasps, attributes, operations, em., as necessary 

b) Subdivision: Qrouptog classes into packages. (AttributM _ ^ ^ 
assigned to classes when they are introduced) 

25 e) Assigning responsibilities: Every package, class, and opemtion should have a clear and 
concisely described responsibility. 

W< ^^ e ^~«^«d<,mm<^ toa rriveatad*signth«is 
~ aPmiUaWy - Feedback towards me recruiremerns specifics process 

object model are changed by the FRS authors and me OMCT. 

In any case, the result of these steps Is a design object model that is a pure 
«~ of me remnrements object model. The most important advantage of mis is the 
enhanced Uaceabiliry: The rehmonsbip between me terns In the req uirements model and me 
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ones in the design model is clear. At first sight, insisting mat the requirements model is a 
pure subset of the design model seems a very strong constraint: While the requirements 
model is constructed, little or no thought is given to the design, and still the requirements 
model shapes the design to a significant degree. Nevertheless, the following two principles 
5 make sure mat the designers have enough freedom to come up with an effective and efficient 



The requirements object model contains only those items that are necessary to 
explain what happens in the system. The items related to how things happen (e.g., control and 
interface classes) do not belong to the requirements model and can therefore be added in 
1 0 complete freedom by the designer. 

Responsibilities are not assigned to items in the requirements workflow, but this is left to the 
design. This again provides the designer with the freedom to assign the responsibilities m a 
suitable way. For example, when the requirements model says that a class has an attribute, 
this does not mean that the class also has the responsibility to store the value of that attribute. 
15 Instead, the value can be stored somewhere else or computed whenever needed. 

As already mentioned above, the method according to the invention was applied and refined 
in a large development project tor a family of X-ray systems. The requirements object model 
for that project became quite large, containing about 100 diagrams, 700 classes, 1000 
relationships and 1500 attributes. This way of requirements modeling and specification laid a 
solid and stable basis of shared knowledge for further development and mat the effort was 
well spent Even when the specifications changed somewhat during the project, only minor 
modifications to the object model were necessary. Several smaller feasibility studies have 
confirmed that this approach is suitable over a wide range of professional electronic systems. 
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1. A method for developing a family of complex systems having a common 

software architecture platform, the method comprising 

- set up of a functional requirements specification which includes use cases that describes 
interaction of users with said complex systems in terms of abstract concepts 

5 - set up of a requirements object model which explains the abstract concepts in terms of a 
structured vocabulary 
wherein 

- the use cases are developed hand-in-hand with the requirements object model. 

10 2 - A method as claimed in Claim 1, wherein 

- the functional requirements specification includes one or more chapters and one or more 
FRS authoring teams are established for separate chapters 

- a single object model control team control internal consistency of the requirement 
object model 

- one or more overlapping modeling teams are formed where each modeling team 
includes members of the object model control team together with one or more 
members of respective FRS authoring teams, 

- which overlapping modeling teams for their chapters construct use cases and provide 
respective portions of the structured vocabulary. 
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3. 



A method as claimed in Claim 1, wherein differences between members of the 
femily are expressed in the requirements object model, notably using one or more of the 
following mechanisms: 

- Different members of the femily using different subclasses of a generalised class, 

- Different members of the family using different multiplicities in relationships between 
classes, 

- Different members of the family using different values for an attribute of a class. 
4 - A method as claimed in Claim 2, wherein 
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- in at least one of the modeling teams an initial model is constructed and 

- die FRS authoring of the use cases is performed on die basis of the initial model and 
_ fine tuning of the use cases is performed by the object model control team. 

5 5 A method as olahned in Claim 2, wherein 

_ FRS authoring of the use cases of several chapters is carried out in parallel by the 
respective FRS authoring teams. 

6. A method as claimed in Claim 1 . wherein the complex systems are medical 
10 diagnostic imaging systems, notably, diagnostic x-ray examination systems. 

7. A family of complex systems, notably a family of medical imaging systems, 
_ separate complex systems supporting respective, different subsets of use cases. 

15 g A method as claimed in Claim la, where the precise behaviour of one or more 

use cases differs among members of the family according to variations expressed in the 
object model notably by different subclasses of a general class, by different multiplicities of 
relationships, or by different values of attributes. 
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_„ ia *» ^eloping a family of complex systems having a 

common software architecture platfona< ^ mc±Qd 

- set up of a functional requirements specification rFR<5\ , • . . 

.... ^««ua apccuication (rRS) which includes use cases that 

«« up of, regents ^ ^ which explains the abstract concepts to JT of a 
structured vocabulary 

He use cases are developed I.***,* ^ «. mpiiKaaia ^ ^ 

„„,,„. ^ J*" specifies *. interaction 0 f ^ ^ ^ ^ 

N ° te ly - *• 8peCifl « *• which are performed ia the interaction of thT' 

,~ 1 ^ m0de ' » «*<*« specified 7L PR* 

model a written .a an object modeling language such as UML. 
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